<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html lang="en">
<HEAD>

<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2012. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">

<LINK REL="STYLESHEET" HREF="../book.css" CHARSET="ISO-8859-1" TYPE="text/css">
<TITLE>Plug-ins and bundles</TITLE>

<link rel="stylesheet" type="text/css" HREF="../book.css">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H3>
Plug-ins and bundles</H3>
<p>
The mechanics for supporting plug-ins are implemented using the <a href="https://docs.osgi.org/specification/osgi.core/7.0.0/">OSGi</a> framework.  From this
standpoint, a plug-in is the same thing as an OSGi <b>bundle</b>.  The bundle and its associated classes specify and implement
the process for Java class-loading, prequisite management, and the bundle's life-cycle.  For the rest of this discussion, we use
the terms <b>plug-in</b> and <b>bundle</b> interchangeably, unless discussing a particular class in the framework.  
</p>
<h4>Plugin</h4>
<p>
The <b><a href="../reference/api/org/eclipse/core/runtime/Plugin.html">Plugin</a></b> class represents a plug-in that
is running in the platform.  It is a convenient place to centralize the life-cycle aspects and overall 
semantics of a plug-in.  A plug-in can implement specialized functionality for the <b>start</b> and <b>stop</b>
aspects of its life-cycle.  Each life-cycle method includes a reference to a  
<b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/BundleContext.html">BundleContext</a></b> which can supply
additional information.</p>
<p>
The <b>start</b> portion of the life-cycle is worth particular discussion.  We've seen already that information 
about a plug-in can be obtained from the plug-in's manifest file without ever running any of the 
plug-in's code.  Typically, some user action in the workbench causes a chain of events that 
requires the starting of a plug-in.  From an implementation point of view, a plug-in is
never started until a class contained in the plug-in needs to be loaded.
</p>
<p>
The <b>start</b> method has been a convenient place to implement initialization and
registration behavior for a plug-in.  However, it is important to realize that your plug-in
can be started in many different circumstances.  Something as simple as obtaining an icon to decorate
an object can cause one of your plug-in's classes to be loaded, thus starting your plug-in.  Over-eager 
initialization can cause your plug-in's code and data to be loaded long before it is necessary.  Therefore,
it's important to look closely at your plug-in's initialization tasks and consider alternatives
to performing initialization at start-up.</p>
<ul>
<li><b>Registration</b> activities such as registering listeners or starting background threads are appropriate
during plug-in start-up if they can be performed quickly.  However, it is advisable to trigger these
actions as part of accessing the plug-in's data if the registration activities have side-effects such
as initializing large data structures or performing unrelated operations. </li>
<li><b>Initialization</b> of data is best done lazily, when the data is first accessed, rather than automatically
in the start-up code.  This ensures that large data structures are not built until they are truly necessary.</li>
</ul>

<h4>Bundle Context</h4>
<p>
Life-cycle management is where the OSGi &quot;bundle&quot; terminology and the platform's 
&quot;plug-in&quot; terminology meet.  When your plug-in is started, it is given a reference to a <b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/BundleContext.html">
BundleContext</a></b> from which it can obtain information related to the plug-in.  The
<b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/BundleContext.html">BundleContext</a></b>
can also be used to find out about other bundles/plug-ins in the system.  
</p>
<p>
<b>BundleContext.getBundles()</b> can be used to obtain an array of all bundles in the system.  Listeners for
<b>BundleEvent</b> can be registered so that your plug-in is aware when another bundle has a change
in its life-cycle status.  See the javadoc for 
<b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/BundleContext.html">BundleContext</a></b> and
<b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/BundleEvent.html">BundleEvent</a></b> for more information.
</p>
<blockquote><i>
Prior to 3.0, a plug-in registry (<b>IPluginRegistry</b>) was provided to supply similar information.  For example,
it could be queried for the plug-in descriptors of all plug-ins in the system.  This registry is now deprecated and
<b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/BundleContext.html">BundleContext</a></b> should be
used for this purpose.  The platform registry is now used exclusively for information about extensions 
and extension points.
</i></blockquote>
<h4>Bundle Activator</h4>
<p>
The <b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/BundleActivator.html">BundleActivator</a></b> interface defines
the start and stop behavior implemented in 
<b><a href="../reference/api/org/eclipse/core/runtime/Plugin.html">Plugin</a></b>.  Although the
<b><a href="../reference/api/org/eclipse/core/runtime/Plugin.html">Plugin</a></b> class is a convenient place
to implement this function, a plug-in developer has complete freedom to implement the interface for
<b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/BundleActivator.html">BundleActivator</a></b> in any class
appropriate for the plug-in's design.  In fact, your plug-in need not implement this interface at all if it
does not have specific life-cycle management needs.  </p>
<h4>Bundles</h4>
<p>
Underneath every plug-in lies an OSGi bundle managed by the framework.
The <b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/Bundle.html">Bundle</a></b> is the OSGi unit of modularity.  Fundamentally, a 
bundle is just a collection of files (resources and code) installed in the 
platform.  Each bundle has its own Java
class loader, and includes protocol for starting, stopping, and uninstalling itself.  From the Eclipse platform 
point of view, <b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/Bundle.html">Bundle</a></b> is merely an implementation 
class.   Plug-in developers do not extend the bundle class, but use <b><a href="../reference/api/org/eclipse/core/runtime/Plugin.html">Plugin</a></b>
or other <b><a href="https://docs.osgi.org/javadoc/osgi.core/7.0.0/org/osgi/framework/BundleActivator.html">BundleActivator</a></b> implementations
to represent the plug-in.</p>


</BODY>
</HTML>


